Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Object names and filename extensions

At this point it is worth noting that the full pathname of a static object can be represented in the Repository in as many as three separate parts. The relative pathname to the file is stored in the object_path field in the ryc_smartobject table. The object name is stored in the object_filename field. The filename extension is stored in a separate field called object_extension, and the object_filename field holds only the simple filename without any extension. For procedural objects created, the filename extension is stored along with the filename in the object_filename field. Progress Dynamics handles both object name forms properly and consistently.

In the case of a dynamic object, which has no physical source file, there is no object_path or object_extension, and the object_filename (somewhat misleadingly named in this case, since it is just a logical name and not an actual filename) is the name given to the object, which for dynamic objects never has an extension.

The naming convention, in which the object_filename is always just the simple name of the object, whether it is procedural or dynamic, promotes consistency. It also makes it easier to convert static objects, such as static viewers and SDOs, to dynamic objects of the same type, without a change to this important object_filename key field. For now, it is important to understand that you can store procedural objects with or without the extension in the filename, though for newly created objects it is always stored separately. Framework code that relies on the name is prepared to deal with both forms to preserve compatibility, but you should not rely on the presence of the extension in your work.

Note also that this convention does mean, for example, that you cannot have a window (.w) and a procedure (.p) file with the same base name in your application. But this restriction really existed already, because both of these files in the same directory would compile to a single r-code (.r) file. The names must be unique without considering the directory, so they would not be allowed in different directories either. This restriction is also necessary to support Roundtable.